Within a message delivery system, messages may generally be delivered through a network of servers (“brokers”) which provide routing and formatting services. Such communications often have an associated “quality of service” which determines the manner in which the brokers process the message. Known quality of service characteristics include factors such as network bandwidth requirements, throughput, latency, error rate, compression, encryption, or the amount of memory or buffer space required for a data flow.
Many message brokers support the publish/subscribe communication paradigm. This involves a set of one or more publishers sending communications to a set of one or more subscribers who have registered their interest in receiving communications of that type. Publish/subscribe allows subscribing users to receive the very latest information in an area of interest (for example, stock prices or events such as news flashes or store specials). A typical publish/subscribe environment has a number of publisher applications sending messages to a number (potentially a very large number) of subscriber applications located on remote computers across the network. Publish/subscribe solutions typically include one or more message brokers located at a communications hub via which the publishers and subscribers communicate. In this case, the subscribers notify the broker(s) of the message types they wish to receive and this information is stored at the broker. Publishers send their messages to the broker, which compares the message type (for example, checking message header topic fields or checking message content) with its stored subscriber information to determine which subscribers the message should be forwarded to. The message broker may perform additional functions, such as filtering, formatting or otherwise processing received messages before forwarding them to subscribers.
Currently, typical message brokers communicate with each other using a single transport mechanism. This mechanism may not have the most desirable behaviour for all qualities of service, with the result that many messages are not processed in the most efficient manner. Broker software may implement higher qualities of service than that provided by the communication mechanism itself, but this is typically complicated and can result in systems which are difficult to administer. The alternative is to always use a transport mechanism which supports the highest qualities of service, but this incurs overheads when processing messages which only require lower qualities of service such that many messages are not handled in the most efficient manner.
U.S. Pat. No. 5,537,417 discloses a socket structure for a multi-protocol environment which moves the decision on which protocol to use for communication until the time that the connection is actually made between nodes in the network. This is an alternative to a socket having a single associated protocol which is fixed at the time the socket structure is created. A single protocol is used for all communications via the connection.
U.S. Pat. No. 5,995,503 discloses a system in which routers within a network calculate a communication path through the network which can satisfy a quality of service request. The calculations are performed based on information about available link resources and resource reservations for the network nodes. U.S. Pat. No. 5,995,503 discloses identifying an acceptable network path and avoiding links which have inadequate resources, but there is no disclosure of route or protocol selection to achieve improved efficiency when a high quality of service is not required.
IBM Corporation's book “IBM Lakes—An Architecture for Collaborative Networking”, R. Morgan Publishing, UK, 1994, describes a framework for real-time multimedia communications. Chapter 1 “Architecture fundamentals” includes a disclosure of communication end point applications exchanging information about their quality of service requirements. The Lakes components then select different network paths (link types and channels) and allocate resources according to the specified quality of service requirements, enabling multimedia applications to exchange multimedia data for effective collaborative working. Although Lakes provided invaluable support for collaborative multimedia applications, it was not applicable to communications between message brokers in a publish/subscribe environment (see below) in which endpoint applications typically have no dedicated end-to-end connection.
U.S. Pat. No. 6,101,545 discloses a message handling system in which a sender can specify a message delivery type to designate whether a message is delivery critical or time critical. A message delivery selector then selects a protocol (for example, TCP or UDP) based on the message delivery type. Thus, the sender of a message can specify a message delivery type which is analyzed and used to control selection of a message transport protocol, but no information about the intended recipient of the message is involved in this selection. In a message broker environment, any attempt to implement a solution based on U.S. Pat. No. 6,101,545 would result in many messages still being processed inefficiently because a high quality of service specified by a sender will be honoured even if not required by the recipient.
Thus, there is a need for a more efficient solution for message broker networks, which avoids the current compromise between either satisfying quality of service requirements or achieving efficient message processing.